this will not work after all...
missing @glimmer/runtime in the client app and other required ones...

Reopen, this could minimise the setup clients need to do to get inspector working

@patricklx this seems to break Ember < 3.28. If this is something we are going to need, we will have to cut a new legacy branch and make the main branch only support Ember 3.28+

I could probably support older versions as well. But we need a compat adapter anyway. This just reduces it

🎉
it works, but I don't think we gain much.
So, just a nice proof of concept. :)

It reduces the deps on client ember to

• @ember/runloop
• @ember/-internals/views
• @ember/instrumentation
• @ember/debug
• @ember/-internals/utils
• @ember/object/internals
• @glimmer/component
• @glimmer/runtime
• rsvp
• ember

@NullVoxPopuli @RobbieTheWagner
Do you think it makes sense to continue work on this?
I can try to remove the require('ember') call as well and use direct imports of the needed deps

maybe -- I'm not entirely sure what the purpose is -- in my 5.2 app with staticEmberSource enabled, I still get an error:

does this work make progress towards fixing that? I presume by somehow adding in modules that an app may not have?

Well, this will at least reduce those issues.
Whats missing there for example is the runloop, specifically, the backburner export.
But that is required to have from the client app. And having that export will not increase your apps size.
The biggest issue i think is the dependency on require ember, but ember_debug does not actually need all.

Actually, we could also fallback to own runloop, but then we need to have a setup a interval, so that backburner will be invoked.
Will then be poll based instead.

this now works on limber
but

• no tracked detection
• polling based
• current inspect object is also iterated over all props without checking for changes (need @glimmer/validator)
• no promise inspection (need rsvp)
• no data tab (maybe you do not have?)

Why close?

This fixes only half of the problem.
It makes ember_debug use it's own ember. But it still needs access to multiple parts of the clients ember to do the debugging.
And all the parts ember_debug depends on, are already in the clients ember, also with static ember. Just not exposed via the amd loader.
I think ember_debug could also be refactored to reduce usage of ember and instead use more native things like classes and getters. Which would also reduce the dependency on ember object, computed etc

One idea someone had yesterday was to:

• make ember inspector wholly use its own ember-source
• have ember-source provide an "adapter" to hook in to the inspector, the same way ember-data does -- that way ember-source is responsible for compatibility, rather than the inspector. This could also lead to user-land customizations / enhancements of how things show up. And it would solve the missing modules problem, because everything needed would be "await imported" by the app.

thoughts?

Sounds good to me. could be backported to earlier ember versions?
There is actually already ember/debug for that.
The problem is in earlier versions it did not provide enough debug tooling for specific things like tracked detection and tracked dependency detection.
Which is done now in a hacky way.

could be backported to earlier ember versions?

at the very least LTSes -- but it's not unheard of for folks on older embers to use older ember-inspectors

I think this is a slippery slope to try to have ember_debug ship its own Ember. It runs in the context of your app, so as Ember changes, it's going to be constant whack-a-mole trying to make all the things work. I personally think it's okay if a user decides to strip out parts of Ember in production and Ember Inspector doesn't work then. It should still work in dev mode.

If we want to build public APIs into ember-source for compatibility, I am all for that. Not using hacks, and instead using a tailor made API that just does all the debug stuff would be much preferred and would guarantee we don't break inspector in the future.